…prepass

prepass-workflow-integrity.py only walked the skill root and matched
the legacy `^\d+-` filename pattern. That made it miss every BMad
skill that uses the modern `steps-c/step-NN-<slug>.md` layout
(enforced by `tools/validate-skills.js` STEP-04 in downstream modules
like skill-forge): the walker found zero numbered files at the skill
root, then matched the SKILL.md references against an empty
actual-files set, producing 5+ false-positive `critical/missing-stage`
findings on every quality scan of every affected skill.

Three coordinated changes to fix it:

- New `discover_step_files()` helper walks the skill root AND the
  conventional stage subdirectories (`steps-c/`, `steps-a/`,
  `steps-b/`, `prompts/`). Walks recursively (`rglob`) inside each
  to pick up nested layouts like `steps-c/sub/` for sub-step files
  (used by skill-forge's create-skill workflow, among others).
- Filename regex broadened from `^\d+-` to `^(?:step-)?\d+\w*-` so
  it accepts both legacy `01-foo.md` and modern
  `step-01b-foo.md` (letter suffixes for sub-stages).
- Reference-matching regex broadened from `(?:prompts/)?(\d+-…)`
  to allow any of the four stage-subdirectory prefixes plus
  optional nested path segments, so `steps-c/sub/step-02b-...`
  references resolve correctly. Both the SKILL.md side and the
  filesystem side now produce posix-style relative paths from the
  skill root, so cross-platform comparison is byte-identical.
- Stage-numbering check updated to match the broader filename
  pattern and to dedupe by integer (so `1, 1b, 2, 3` no longer
  reports a phantom gap — `1b` is a sub-stage of `1`, not a missing
  number).

Verified against the bmad-module-skill-forge SKF-* skill suite (7
skills): all now show 0 critical findings, 0 missing-stage entries,
0 orphaned-stage entries, and the correct stage count. Remaining
high/medium findings on each skill are real workflow content issues,
not the false-positive class fixed here.

Tests: 11 passing in skills/bmad-workflow-builder/scripts/tests/
test_prepass_workflow_integrity.py covering discovery for all four
stage-subdir conventions, the legacy root layout, nested
sub-directories, letter-suffix sub-stages, the well-formed
"1, 1b, 2, 3" sequence (no phantom gap), plus regression coverage
asserting that genuinely missing or orphaned stages are still
flagged.

…F021)

CodeRabbit caught two compounding bugs on PR bmad-code-org#82's
test_cross_reference_no_false_positive_critical_for_steps_c
assertion:

1. Operator precedence (RUF021). The expression

       category == 'naming' and 'orphaned' in issue or 'not referenced' in issue

   evaluated as

       (category == 'naming' and 'orphaned' in issue)
       or ('not referenced' in issue)

   because Python's `and` binds tighter than `or`. The right-hand
   disjunct matched ANY finding whose issue text contained
   "not referenced" — regardless of category. A non-orphan
   finding (e.g. a hypothetical frontmatter check that mentioned
   "not referenced" in its message) would have slipped into the
   orphan list and made the assertion stricter than intended in
   one direction while still permitting genuine orphan misses to
   pass in another.

2. Dead substring. The actual orphan finding text per
   prepass-workflow-integrity.py:276 is exactly

       Stage file exists but not referenced in SKILL.md: <name>

   The word "orphaned" never appears in it. The
   `'orphaned' in issue.lower()` clause is therefore dead code
   that could never match. The assertion was effectively only
   the un-parenthesised OR branch from problem 1.

Fix: replace the bug-prone expression with a canonical-prefix
match against the exact string the script emits. The new check
matches the finding shape directly:

    category == 'naming' AND
    issue.startswith('Stage file exists but not referenced in SKILL.md')

This is precise (no category-leaks), readable (no precedence
trap), and maintainable (locked to the prefix the producer
actually uses — easier to grep for if either side changes).

Also updates the matching positive-direction check in
test_genuinely_orphaned_stage_is_still_caught for symmetry, so
both tests share one definition of "what an orphan finding looks
like". That assertion was not buggy (no `or`, and "not referenced"
substring does appear in the finding text), but standardising
the pattern across both tests prevents a future contributor from
copy-pasting the older `'not referenced' in issue.lower()` shape
into a new test that adds another condition with `or` and trips
the same precedence trap.

All 11 tests in test_prepass_workflow_integrity.py still pass.

Refs: CodeRabbit comment on PR bmad-code-org#82